==============================================================
Guild: wafer.space Community
Channel: ℹ️ - Information / general / speaking of multi-threading, last
After: 2026-03-31 11:59 p.m.
Before: 2026-05-01 12:00 a.m.
==============================================================

[2026-04-07 7:09 a.m.] mole99



[2026-04-07 7:09 a.m.] mole99
Would you be willing to open an issue, or perhaps even contribute to LibreLane?

If enabling certain options would provide some speed improvements, that would definitely be appreciated. At first glance, I didn't see anything obvious in [Gate Resizer](https://openroad.readthedocs.io/en/latest/main/src/rsz/README.html).


[2026-04-07 3:26 p.m.] polyfractal
ahhh sorry, that's what I get for responding without looking at my code changes.

I meant OpenSTA not resizer, my bad! I can disentangle the change from the rest of my stuff and send a PR, was a minor tweak to openroad.py in the OpenSTAStep.

(also added a blanket thread parameter since it looked like some other steps could take threads but I don't think that had much effect and is probably not very principled. Might have been redundant too)


[2026-04-07 5:56 p.m.] mole99
Right! Yes, OpenSTA added native multithreading in its recent 3.0 release afaik.

Donn added [a compatibility layer](https://github.com/librelane/librelane/pull/881) to LibreLane, so we can continue using the same scripts for the LibreLane 3.0 release.

Currently, LibreLane spawns an OpenSTA process for each corner using the [MultiCornerSTA](https://github.com/librelane/librelane/blob/b1095babdafd1d0ceb8182b39a2485989903a81c/librelane/steps/openroad.py#L710) class.
This was great at the time and definitely better than running each corner sequentially ^^
However, if you only have three corners, like on gf180mcu, there isn't much to be gained.

Doing multithreading directly in OpenSTA is a major improvement, as many more threads can probably be used in parallel this way. It also means that we only need to keep the database in memory once, reducing the memory footprint and (likely) increasing cache hits. So running OpenSTA multithreaded is definitely desired :)


[2026-04-07 5:57 p.m.] mole99
How did you modify LibreLane to run OpenSTA multithreaded? You should probably make sure that OpenSTA is only spawned once. Otherwise, you could end up with more software threads than hardware threads.


[2026-04-07 5:57 p.m.] mole99
By default, each step should try to use up to `--jobs` threads if possible. This is done [here](https://github.com/librelane/librelane/blob/b1095babdafd1d0ceb8182b39a2485989903a81c/librelane/steps/klayout.py#L512), for example. As you can see, each step should also have local overrides e.g. in case running DRC with all available threads exhausts the system memory.


[2026-04-08 4:42 p.m.] polyfractal
ahh good to know! I was only running small tests, will rerun with my full design to see if I accidentally blow up the machine 🙂

> How did you modify LibreLane to run OpenSTA multithreaded?

IIRC I was just passing in `-threads` when invoking OpenSTA process. It was a very small / targeted change


[2026-04-08 4:42 p.m.] polyfractal
will doublecheck when i get home


[2026-04-09 7:23 a.m.] mole99
Haha, it won't blow up the machine, but it could potentially slow things down because of all the context switching 😁

Good to know that's all that's needed. So, we just need to disable the explicit multiprocessing in LibreLane and enable `-threads`.


==============================================================
Exported 9 message(s)
==============================================================